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This Technical Specification (TS) has been produced by the ETSI 3 Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3 GPP identities or GSM identities. 
These should be interpreted as being references to the corresponding ETSI deliverables. The mapping of document 
identities is as follows: 

For 3 GPP documents: 

3G TS I TR nn.nnn "<title>" (with or without the prefix 3G) 

is equivalent to 

ETSI TS I TR Inn nnn "[Digital cellular telecommunications system (Phase 2+) (GSM);] Universal Mobile 
Telecommunications System; <title> 

For GSM document identities of type "GSM xx.yy", e.g. GSM 01.04, the corresponding ETSI document identity may be 
found in the Cross Reference List on www.etsi.org/key 
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Foreword 

This Technical Specification has been produced by the 3 GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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1 Scope 

This document specifies the content of the stage one requirement for reaUsation of VHE. 

Virtual Home Environment (VHE) is defined as a concept for personal service environment (PSE) portability across 
network boundaries and between terminals. The concept of the VHE is such that users are consistently presented with 
the same personalised features, User Interface customisation and services in whatever network and whatever terminal 
(within the capabilities of the terminal and the network), wherever the user may be located. 

A key feature to support VHE is the ability to build services using a standardised application interface. 

Requirements not applicable for R99 will be explicitly indicated. 

2 References 

References may be made to: 

a) Specific versions of publications (identified by date of publication, edition number, version number, etc.), in 
which case, subsequent revisions to the referenced document do not apply; or 

b) All versions up to and including the identified version (identified by "up to and including" before the version 
identity); or 

c) All versions subsequent to and including the identified version (identified by "onwards" following the version 
identity); or 

d) Publications without mention of a specific version, in which case the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

2.1 Normative references 

[1] GSM 01.04 (ETR 350): "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms" 

[2] GSM 02.57: "Digital cellular telecommunication system (Phase 2+); Mobile Station Application 

Execution Environment (MExE); Service description" 

[3] GSM 02.78: "Digital cellular telecommunication system (Phase 2+); Customised Applications for 

Mobile network Enhanced Logic (CAMEL); Service definition - Stage 1" 

[4] GSM 1L14: "Digital cellular telecommunication system (Phase 2+); Specification of the SIM 

Application Toolkit for the Subscriber Identity Module - Mobile Equipment; (SIM - ME) 
interface" 

[5] UMTS TS 22.01: "Universal Mobile Telecommunications System (UMTS): Service Aspects; 

Service Principles" 

[6] UMTS TS 22.05: "Universal Mobile Telecommunications System (UMTS); Services and Service 

Capabilities" 

[7] ITU-T Recommendation Q.1701, Framework for IMT-2000 networks 

[8] ITU-T Recommendation Q. 1 7 1 1 , Network Functional Model for IMT-2000 

[9] UMTS TS 22.00 UMTS phase 1 



ETSI 



(3G TS 22.1 21 version 3.1 .0 Release 1 999) 6 ETSI TS 1 22 1 21 V3.1 .0 (2000-01 ) 



2.2 Informative references 

[1] UMTS TR 22.70: "Universal Mobile Telecommunications System (UMTS); Virtual Home 

Environment" 

[2] World Wide Web Consortium Composite Capability/Preference Profiles (CC/PP): A user side 

framework for content negotiation (www.w3.org) 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of this TS, the following definitions apply: 

HE-VASP: Home Environment Value Added Service Provider. This is a VASP that has an agreement with the Home 
Environment to provide services. 

Local Service: A service, which can be exclusively provided in the current serving network by a Value added Service 
Provider. 

Service Capabilities: Bearers defined by parameters, and/or mechanisms needed to realise services. These are within 
networks and under network control. 

Service Capability Feature: Functionality offered by service capabilities that are accessible via the standardised 
application interface 

Services: Services are made up of different service capability features. 

Service Execution Environment: a service execution environment is a platform on which an application or programme 
is authorised to perform a number of functionalities; examples of service execution environments are the user 
equipment, integrated circuit card and a network platform or any other server. 

Applications / Clients: These are services, which are designed using service capability features. 

Application Interface: Standardised Interface used by application/clients to access service capability features. 

Personal Service Environment: contains personalised information defining how subscribed services are provided and 
presented towards the user. The Personal Service Environment is defined in terms of one or more User Profiles. 

Home Environment: responsible for overall provision of services to users 

User: is a logical entity, which uses UMTS services. 

User Interface Profile: Contains information to present the personalised user interface within the capabilities of the 
terminal and serving network. 

User Services Profile: Contains identification of subscriber services, their status and reference to service preferences. 

User Profile: This is a label identifying a combination of one user interface profile, and one user services profile. 

Value Added Service Provider: provides services other than basic telecommunications service for which additional 
charges may be incurred. 

Virtual Home Environment: A concept for personal service environment portability across network boundaries and 
between terminals. 



Further UMTS related definitions are given in 3G TS 22.101. 
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3.2 



Abbreviations 



For the purposes of this TS the following abbreviations apply: 

API Application Programming Interface 

CAMEL Customised Application For Mobile Network Enhanced Logic 

CORBA Common Object Request Broker Architecture 

FES For Further Study 

ME Mobile Equipment 

MExE Mobile Station (Application) Execution Environment 

MMI Man Machine Interface 

MS Mobile Station 

MSC Mobile Switching Centre 

HLR Home Location Register 

GSN GPRS Support Nodes 

SSF Service Switching Function 

PLMN Public Land Mobile Network 

HE Home Environment 

SAT SIM AppHcation Tool-Kit 

SIM Subscriber Identity Module 

SMS Short Message Service 

USIM User Service Identity Module 

USSD Unstructured Supplementary Service Data 

VASP Value Added Service Provider 

HE- V ASP Home Environment Value Added Service Provider 

PSE Personal Service Environment 

VHE Virtual Home Environment 

LCS Location Services 

CAP Camel Application Part 

MAP Mobile Application Part 

CSE Camel Service Environment 

OSA Open Service Architecture 
Further GSM related abbreviations are given in GSM 0L04. Further UMTS related abbreviations are given in UMTS 
TS 22.01. 



General Description of the VHE 



Virtual Home Environment (VHE) is defined as a concept for personal service environment portability across network 
boundaries and between terminals. The concept of the VHE is such that users are consistently presented with the same 
personalised features, User Interface customisation and services in whatever network and whatever terminal (within the 
capabilities of the terminal and network), where ever the user may be located. 



The key requirements of the VHE are to provide a user with a personal service environment which consist of: 

■ Personalised services; 

■ Personalised User Interface (within the capabilities of terminals); 

■ Consistent set of services from the user's perspective irrespective of access e.g. (fixed, mobile, wireless etc. Global 
service availability when roaming 



The standards supporting VHE requirements should be flexible enough such that VHE can be applicable to all types of 
future networks as well as providing a framework for the evolution of existing networks. Additionally the standards 
should have global significance so that user' s can avail of their services irrespective of their geographical location. This 
implies that VHE standards should: 
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■ provide a common access for services in future networks; 

■ enable the support of VHE by future networks. 

■ enable the creation of services, 

■ enable personal service environment to be recoverable (e.g in the case of loss/damage of user equipment) 

Roles and components involved in realisation of VHE consist of the following also see fig 1 : 

• Home Environment 

• User Identifiers 

• Users 

• Terminals (simultaneous activation of terminals providing the same service per single subscription is not allowed) 

• Serving Networks 

• Subscriptions 

• Possibly Value added service providers. 

• Personal Service Environment 

• User Profiles 
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Fig 1: Service Provisioning From User's point of View 



The Home Environment provides and controls services to the user in a consistent manner. The User's personal service 
environment is a combination of services and personalisation information (described in the user profile). The user may 
have a number of user profiles which enable her to manage communications according to different situations or needs, 
for example being at work, in the car or at home. Services provisioned to the user may allow or require personalisation 
by the user. 
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The Home Environment provides services to the user in a managed way, possibly by collaborating with HE-VASPs, 
but this is transparent to the user. The same service could be provided by more than one HE-VASP and HE- V ASP can 
provide more than one service. 

Additionally, but not subject to standardisation, the user may access services directly from Value Added Service 
Providers. The Home Environment does not manage services obtained directly from VASPs. A mechanism may be 
provided which allows the user to automate access to those services obtained directly from VASPs and personalise 
those services. However such a mechanism is outside of the scope of this specification. 



5. Framework for Services 



The implementation of VHE in UMTS release 99 shall support both GSM phase 2+ release 99 teleservices, bearer 
services and supplementary services as applied in 3G TS 22.100 and new services built by service capability features. 
Later UMTS developments will provide support for a wider range of services in later releases. 
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Fig 2: Framework for Services. 



The goal of standardisation in UMTS with respect to services is to provide a framework within which services can be 
created based on standardised service capability features see figure 2 and 3. UMTS services will generally not rely on 
the traditional detailed service engineering (evident for supplementary services in second-generation systems), but 
instead provides services using generic toolkits. 

Services can be built using service capability features ([1] [2], [3], [4], [9], [10]), which are accessed via a standardised 
interface. An example of how a service can be built on service capability features could be "call to nearest restaurant", 
this will make use of call set-up, authorisation, location and database lookup. 

The available service capability features are visible to applications through the standardised application interface. The 
application interface can be realised in a non-generic way (implying applications must have knowledge of the 
underlying mechanisms used) and/or a generic way (implying applications need not have knowledge of underlying 
mechanisms used). The functionality provided in both cases is the same and both solutions are independent of vendor 
specific solution. 

For example, in the non-generic way, the User Location service capability features can be provided by a location server 
(e.g HLR, LCS). In the generic way the application will only see a single User Location service capability feature and 
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does not know which location server provides it. 

• The standardised appHcation interface shall be independent of vendor specific solutions, 

• Independent of programming languages, operating systems etc used in the service capabilities. 

• Secure scalable and extensible 



In the case of realising the standardised application interface in the generic way, the following additional requirements 
apply: 

• Independent of the location where service capabilities are implemented, 

• Independent of supported server capabilities in the network and. 

Access to Service Capability Features shall be realised using modern state of the art access technologies, e.g. distributed 
object oriented technique might be considered. 



5.1 Ways to realise services 

The information contained in this clause is only to aid understanding and is not an extensive list. 

Figure 3 illustrates how the concept of VHE makes use of the standardised application interface and how that fits to the 
service capability features and service capabilities for release 99. It is not to be implied as the agreed architecture as this 
is a stage 2 issue. 
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Figure 3 Possible realisation of Framework for Services 
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STANDARDISED SERVICES (Supplementary Services, Tele-Services, etc.) are implemented on existing 
GSM/UMTS entities (e.g. HLR , MSCA^LR and terminal) on a vendor specific basis, using standardised interfaces 
(MAP, etc.) for service communication (e.g. downloading of service data). Availability and maintenance of these 
Services is also vendor dependent. 



OPERATOR SPECIFIC SERVICES (OSS) are not standardised and could be implemented at the GSM/UMTS 
entities (e.g. HLR) on a vendor specific basis or using GSM ph 2+ mechanisms (CAMEL, SAT, MExE). These tool-kits 
use standardised interfaces to the underlying network (CAP, MAP) or use GSM Bearers to transport applications and 
data from the MExE/S AT server to the MS/SIM. The implementation of these operator specific services on the different 
platforms (CSE, MExE/SAT Server, MSs) is done in a completely vendor specific way and uses only proprietary 
interfaces. 



Other APPLICATIONS are like OSS not standardised. These applications will be implemented using standardised 
interfaces to the Service Capabilities (Bearers, Mechanisms). The functionality offered by the different Service 
Capabilities are defined by Service Capability Features. These Service Capability Features will be standardised and can 
be used by the application designers to build their applications. 

Within the terminals Service Capabilities are accessible via the existing MExE and SAT APIs, i.e. there will be no 
service capability features within the terminal. 

The terminal can communicate, using GSM/UMTS bearers, with applications in the network via the service capability 
features defined for MExE- and SAT-servers. 



User Requirements of VHE 



The user shall have the possibility to manage services as well as the appearance of the services. It shall be possible for 
the user to: 

Personalise services. 

Personalised User Interface (within the capabilities of terminals) 

Access services from any network or terminal subject to network capabilities, terminal capabilities and any 
restrictions imposed by the home environment. 

Use services in a consistent manner irrespective of serving network and terminal, within the technical limitations. 

Access new services in the Home Environment. 

Modify a user profile(for example to include new services) from any location 

Activate or deactivate user services. 

Discover which local services are available 

Access local services in a secure manner. 

Interrogate current user service and user interface settings 

select a particular User Profile; 

indicate (on a session by session basis if necessary) to which subscription charges are to be applied to ; 

recover MS resident User Profile information to protect against loss or damage of user equipment. 
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Be aware of limitations of services, which may result from different terminals and or serving network capabilities. 



6.1 Personal Service Environment 

The Personal Service Environment describes how the user wishes to manage and interact with their communications 
services. The PSE is a combination of a list of subscriptions (detailing provisioned services), preferences associated 
with those services, terminal interface preferences and other information related to the user's experience of the system. 
Within the PSE the user can manage multiple subscriptions e.g. both business and personal, multiple terminal types and 
express location and temporal preferences. The Personal Service Environment is defined in terms of one or more User 
Profiles. 

6.1.1 User Profiles 

A combination of different preferences is described by a User Profile. The user can define one or more User Profiles 
according to their needs. 

Each User Profile consists of two kinds of information: 

• interface related information (User Interface Profile); 

• services related information (User Services Profile). 



A User Interface Profile consists of the following type of information: 

• menu settings, e.g. menu items shown, menu structure, the placement of icons; 

• terminal settings, e.g. ringing tone and volume, font type and size, screen and text colour, language, content types 
and sizes accepted 

• network related preferences e.g. language used for announcements, (editor's note: for clarification) 
A User Services Profile consists of the following information: 

• a list of services subscribed to and references to Service Preferences for each of those services if applicable. 
Service Preferences could be information such as redirection numbers, redirection conditions, caller screening lists, 
time-of-day variations etc; 

• service status (active/deactive). 



The user may define one or more User Interface Profiles and many User Services Profiles, but a given User Profile 
consists of a single combination of these. In this way a user could for example have a different User Profile to suit each 
of the three different terminals she owns. The User Services Profile is the same in each case but the User Interface 
Profile is different to suit the display capabilities of each terminal. User Profiles could also exist which use the same 
User Interface Profile but different User Services Profiles. This might simply imply that business calls are forwarded to 
an answering service when the user leaves the office because a new User Profile is now active. 

Where the user has more than one User Profile the activation of a particular one could be done in the following ways: 

• Statically: the user explicit selects one of the User Profiles as the active one; 

• Dynamically: the appropriate User Profile is selected automatically based upon some criteria such as time of day, 
location, terminal used or many other possibilities. 



Each User Profile must have an identity. 



ETSI 



(3G TS 22.1 21 version 3.1 .0 Release 1 999) 1 3 ETSI TS 1 22 1 21 V3.1 .0 (2000-01 ) 



For UMTS Release '99 the information in the User Profiles enables the service capabilities SAT, MExE and CAMEL 
toolkits in R'99 and existing GSM services to support the user's PSE across network boundaries and between different 
terminals. 

It shall be possible for the service capabilities to access the user profile information from the home environment if 
appropriate. 



6.1 .2 User Profiles and Multiple Subscriptions 

The user may wish to manage more than one subscription in their PSE. This would allow them to have a single USIM 
but specify different preferences for the services provisioned in each subscription. In this case the User Services Profile 
will need to detail all of the services provided per subscription and provide references to the service preferences for 
each service. When initiating a chargeable event the user will need to indicate which subscription the charges should be 
applied to. 



6.1 .3 Management of the user profile 



The user and the home environment may modify the user' s characterisation of the Personal Service Environment as 
described in the User Profiles at any time, and changes become effective at the earliest possible opportunity. The home 
environment shall be able to update distributed User Profiles to reflect any user or home environment modification of 
the user' s Personal Service Environment. 

The User Profiles may be stored in the Mobile Station (the SIM or the ME), and/or the home environment. The 
information in User Services Profiles is distributed between the home environment and the MS. In the event of 
loss/damage of mobile station (SIM or ME), the User Profiles must be fully recoverable and be used to reconfigure a 
new mobile station. 

Some aspects of the User Profiles such as aspects related to terminal configuration, must be stored in a standardised 
format to support VHE. 

(Note: To ensure that User Profiles are applicable to as wide a community of terminal and network types as possible, 
existing work on this topic in other standards fora should be considered. One possibility is the work of the World Wide 
Web Consortium on the Composite Capability/Preference Profile [2] . 



6.1 .4 Requirements for Standardisation 

To facilitate the provision of PSE and User Profiles the standard shall: 

• uniquely identify User Profiles; 

• provide a standardised format for describing terminal configuration preferences; 



7 Home Environment Requirements for VHE Provision 

It shall be possible for the home environment to: 

Control access to services depending on the location of the user, and serving network. 

Control access to services on a per user basis e.g subject to subscription. 

Control access to services depending on available service capabilities in the serving network, and terminals 

Manage service delivery based on for example end to end capabilities and/or user preferences 
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Request version of specific services supported in serving network and terminal 

Request details (e.g. protocol versions and API versions) of available service capabilities supported in the serving 
network, and terminals. 

Define the scope for management of services by the user, for services provided by the HE. 

Handle charging for services (as defined in clause 11) 

Inform the serving network of the type of charging (i.e. prepaid or/and postpaid) for any required service. 

Inform the serving network of the threshold set for a given service required by the user and charged on a prepaid 
account. 

Inform the serving network how to manage a service for which the threshold has been reached. 

Manage the prepaid accounts (e.g. increase, decrease the credit, or pass the information to any application which 
manages the credit) 

Deploy services to users or groups of users 

Manage provision of services to users or groups of users 

8 Serving Network Requirements for VHE Provision 

The serving network should not need to be aware of the services offered via the home environment. 

The user/home environment may request capabilities, which are necessary to support, home environment services. 

It shall be possible for the serving network to perform the following: 

The serving network shall support user access to services in the home environment; 

The serving network shall provide the necessary service capabilities to support the services from the home 
environment as far as possible; 

Dynamically provide information on the available service capabilities in the serving network; 

Provide transparent communication between clients and servers in terminals and networks; 

Request the charging information (type of charging, threshold for prepaid services and behaviour if the threshold is 
reached) for any service possibly required by the user; 

Handle the call according to the instructions received by the home environment regarding charging activities. 

Inform the home environment of the chargeable events (e.g. send CDRs,. . .). 



VASP Relationship to VHE 



The user may access services directly from Value Added Service Providers. Services obtained directly from VASPs are 
not managed by the Home Environment and therefore are not part of the VHE offered by the Home Environment. A 
mechanism should be provided which allows the user to automate access to those services obtained directly from 
VASPs and personalise those services. However such a mechanism is outside of the scope of this specification. 

There may be some information, which is shared between the Home Environment and the HE- VASP (for example 
current capabilities). 

The Home Environment may grant the HE-VASP access to standardised service capabilities in order to allow the 
development and deployment of services on behalf of the Home Environment. 

There are no VASP requirements to support VHE. 
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1 Service Capability Features 



Services Capability Features are open, technology independent building blocks accessible via a standardised 
application interface. This interface shall be applicable for a number of different business and applications domains 
(including besides the telecommunication network operators also service provider, third party service providers acting 
as HE-VASPs, etc.). 

All of these businesses have different requirements, ranging from simple telephony and call routing, virtual private 
networks, fully interactive multimedia to using MS based applications. 

The service capability features shall enable applications to make use of the service capabilities (e.g. CAMEL, MExE, 
etc) of the underlying UMTS network in an open and secure way. 

Application/Clients access the service capability features via the standardised application interface. This means that a 
single service capability feature is accessible and visible to application/clients via the method/operation invocations in 
the interface. 

Two different types of service capability features can be distinguished: 

• Framework service capability features: these shall provide commonly used utilities, necessary for the non- 
framework service capability features to be accessible, secure, resilient and manageable. 

• Non-Framework service capability features: these shall enable the applications to make use of the functionality 
of the underlying network capabilities (e.g. User Location service capability features). 



1 0.1 Framework service capability features 

Framework service capability features will be used e.g. for authentication, registration, notification, etc. and provide 
functionality that is independent of any particular type of service. Other commonly used service capability features may 
be added later. 

10.1.1 Authentication service capability feature 

Authentication is used to verify the identity of an entity (user, network, and application). 
Three types of authentication are distinguished: 

• User-Network Authentication. Before a user can access her subscribed applications, the user has to be 
authenticated by the network that provides access to the application. This allows the network to check to what 
applications the user has subscribed to. User-network authentication is handled within the network and therefore 
outside the scope of this specification. 

• Application-Network Authentication. Before an application can use the capabilities from the network, a service 
agreement has to be established between the application and the network. Establishment of such a service 
agreement starts with the mutual authentication between application and network. If a service agreement already 
exists, modification might be needed or a new agreement might supersede the existing. 

• User-Application Authentication. Before a user can use an application or perform other activities (e.g. modifying 
profile data) the application provider must authenticate the user. When the network already authenticates the user, 
authentication is not needed anymore. When the network is transparent and the user accesses an application 
directly, authentication is needed between user and application but this is outside the scope of this specification. 

10.1 .2 Authorisation service capability feature 

Authorisation is the activity of determining what an authenticated entity (user, network, and application) is allowed to 
do (note: authentication must therefore precede authorisation). 
Two types of authorisation are distinguished: 

• Application-Network Authorisation. The network verifies what non-framework service capability features s (or 
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even some framework service capability features) the application is allowed to use. Once an application has been 
authorised to use one, more or all (non-framework) service capability features no further authorisation is required 
as long as the "allowed" (non-framework) service capability features are used. 

• User-Application Authorisation. The application verifies what actions the user is allowed to perform (e.g. 
[deactivation of functionality, modification of application data). This is transparent to the network and therefore 
outside the scope of this specification. 

10.1 .3 Registration service capability feature 

The Registration service capability feature enables the non-framework service capability features (e.g. User Location) 
to register at the Framework. Registration must take place before authorised applications can find out from the 
Framework which non-framework service capability features are available. This means that the non-framework service 
capability features must be registered before they can be discovered and used by authorised applications. 

Note that only the non-framework service capability features have to be registered. The Framework service capability 
features (defined in section 10.1) are available by default since they provide basic mechanisms. 

10.1 .4 Discovery service capability feature 

The Discovery service capability feature enables the application to identify the total collection of service capability 
features that it can use. Upon request of the application, the Discovery service capability feature will indicate the non- 
framework service capability features that are available for the application. The list of available service capability 
features is created through the Registration process described in section 10.1.3. This means that a service capability 
feature must be registered at the Framework before it can be discovered by the application. 

10.1 .5 Notification service capability feature 

The Notification service capability feature allows applications to enable, disable and receive notifications of application 
related events that have occurred in the underlying GSM/UMTS network, e.g. indication that a new call is set-up or a 
message is received. 

Note: It should be further studied if Notification is only a Framework service capability feature or also specialised as 
non-framework service capability features (e.g. for notifications on location update, disconnected party etc.) 



1 0.2 Non-Framework service capability features 

The Non-Framework service capability features represent the total collection of service capability features that are not 
included in the Framework. These non-framework service capability features enable the application to make use of the 
functionality provided by the network and service capabilities. 

Service capability features shall be defined as much as possible in a generic way to hide the network specific 
implementation. To achieve this, it is necessary to identify the functionality that is provided by more than one service 
capabilities. For example. User Location can be produced in several underlying ways. This functionality can be 
captured once when defined the service capability features in a generic way. It is important that the generic part 
becomes as large as possible. 

When applications use the generic service capability features, these applications become independent of (portable over) 
underlying service capabilities. Applications shall however still be able to request service capability features specific to 
a service capability (e.g. Call Setup from CAMEL). This will increase dependency of the used service capability. 

The following sections define generic service capability features e.g. for Session Control and Message Transfer. 

10.2.1 Session Control service capability features 

This section details the Session Control related service capability features. Session Control service capability features 
shall offer the functionality to establish, maintain, modify and release bearers to/from other parties or entities. 
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Herein, the term "session" can mean anything from a simple voice call to a complex multimedia "call" (including 
exchange of non delay-sensitive data). To define the necessary service capability features it is proposed to use a generic 
model (including the "session party handling"). 

For example, the following Session Control service capability features shall be provided (the list is not exhaustive): 

initiate and create session (e.g. used to set-up a Telephony session "out of the blue") 

allow the session to continue with modified information (e.g. changed destination number) 

release the session (i.e. removing all parties from the session) 

add bearer to the session 

remove bearer from the session 

resume bearer to the session (i.e. move party from "on-hold" into Telephony Session) 

suspend bearer from the session (i.e. move party from Telephony Session to "on hold") 

request session information (i.e. information like session duration, session end time) 

supervise session (e.g. monitor for session duration or data volume, tariff switching moments and changes in QoS) 

presentation of, or restriction of, information associated with a party involved in a session (e.g. calling line ID, 
calling name) 

For each session it shall be possible to specify: 

• the desired media type (e.g. video, voice, non-real time data etc.) 

• the events on which monitoring is required ([3]) 

Note: the mapping to service capabilities is for further study. (It shall be investigated to which extend the requirements 
above fit to CAMEL, MEXE and other service capabilities.) 

1 0.2.2 Security/Privacy service capability features 

For the Security/Privacy the following service capability features shall be supported: 

• encryption of user data and signalling; 

1 0.2.3 Address Translation service capability features 

The Address Translation enables the application to find out from the underlying network what the user's addresses are. 
Based on a known user address, the application may request another address (e.g. based on the E.164 number, the user's 
e-mail is retrieved). The range of addressing options includes: 

• E.164 Numbering (e.g. GSM MS-ISDN); 

• ASE A Numbering (ATM) ; 

• IP v4 numbering; 

• IP v6 numbering; 

• X.25 Numbering; 

• Internet symbolic naming. 

1 0.2.4 User Location service capability features 

The User Location service capability features provide an application with information concerning the user' s location. 
The user location information contains the following attributes: 

• location (e.g. in terms of universal latitude and longitude co-ordinates) 

• accuracy (value depending on local regulatory requirements and level of support in serving/home networks; note 
that the accuracy of the serving network might differ from that in the home environment) 
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• age of location information (last known date/time made available in GMT) 

The following service capability features shall be provided: 

• Report of location information 

The application shall be able to request user location information. 

By default the location information is provided once; the application may also request periodic location reporting 

(i.e. multiple reports spread over a period of time) 

• Notification of location update 

The application shall be able to request to be notified when the user's location changes, i.e. when: 

• the user enters or leaves a specified geographic area 

• the user' s location changes more than a specified lower boundary. The lower boundary can be selected from 
the options provided by the network. 

The application shall be able for each user to start/stop receipt of notifications and to modify the required accuracy 
by selecting another option from the network provided options. 

• Access control to location information 

The user shall be able to restrict/allow access to the location information. The restriction can be overridden by the 
network operator when appropriate (e.g. emergency calls j. 

1 0.2.5 User Status service capability features 

The User Status service capability features enable an application to retrieve the user's status, i.e. to find out on which 
terminals the user is available. 

The following service capability features shall be provided: 

• Retrieval of User Status 

The application shall be able to retrieve the status of the user 

• Notification of User Status Change 

The application shall receive notifications when the user's terminal attaches or detaches. 

• Detach: the user's terminal is switched on or the network initiates detach upon location update failure 

• Attach: the user's terminal is switched on or there has been a successful location update after network 
initiated detach. 

The application shall be able for each terminal to start/stop receipt of notifications. 

1 0.2.6 Terminal Capabilities service capability features 

f * Editor's note: this section needs to be checked against the MExE specifications *j 

The Terminal Capabilities service capability features enable the application to find out what capabilities the user's 
terminal supports (note: "terminal" covers both (mobile) equipment and USIM). 

The following service capability features shall be provided: 

• Retrieval of Terminal Capabilities 

The application shall be able to retrieve the capabilities of the terminal. This includes: 

• the media that the terminal is capable to deal with (e.g. audio, video, PC data, WAP data; this information is 
needed by the application e.g. when the user wants to download messages from the mailbox); 

• the number of calls that the terminal can deal with simultaneously. 
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1 0.2.7 Message Transfer service capability features 

The Message Transfer service capability features enable an application to put a message in the user's mailbox and to 
send message notifications to the user. A message can e.g. be of type video, audio, e-mail, fax, SMS etc.; a message can 
also contain an attachment (e.g. a video file attached to an e-mail). 

The following service capability features shall be supported: 

• Send message to mailbox 

The application shall be able to put a message in the user's mailbox. The application can e.g. leave a message for a 
user indicating a missed call. The type of the message (video, audio, e-mail) needs to be specified. Messages may 
contain attachments. 

• Send message to user 

The application shall be able to send a message to the user directly (i.e. the message is not stored in the mailbox). 
Examples are a fax message and an announcement like "your call is being diverted". 

• Get message from mailbox 

The application shall be able to fetch a message from the mailbox (when requested by the user to do so). 

• Send message notification 

The application shall be able to send a notification to the user e.g. when it has put a message in the mailbox or 
when it has received a notification from the mailbox that a new message has arrived for the user. 

• Request message receipt notification 

The application can request to receive a notification every time a message is received in the mailbox for the user. 
This allows the application to take the appropriate action, e.g. informing the user. 

• Collect message/data from user 

The application shall be able to collect a message/data from the user. For example, the user might enter a PIN code. 

1 0.2.8 Data Download service capability features 

To allow the support of home environment / serving network specific services the following service capability features 
shall be supported; 

• capability to download applications, data to the terminal; 

• capability to download applications, data to the USIM; 

1 0.2.9 User Profile Management service capability features 

The User Profile Management service capability features allow the application to retrieve the user profile (see section 
7.1 for more information on user profiles). 

10.2.10 Charging service capability features 

The Charging service capability features enable the application to instruct the network and inform the user with 
charging information and to add some additional charging information to the network generated Call Detail Records. 

The following service capability features shall be provided: 

• Define and manage the threshold (e.g. session duration, data volume) for the required service, 

• Send charging data (this data is included in a "free format" field in the network generated Call Detail Records. It 
may contain information like a application generated Call Id, used by the application provider to relate application 
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generated charging information to the network generated charging information) 
• Transfer of Advice of Charge data (as defined in GSM02.24) to the terminal. 



1 1 Service execution environment 

The following service execution environments shall be standardised and could be used to provide a VHE for the user: 

• User equipment execution environment 

• IC card execution environment 

• Network execution environment not required for R99 

For UMTS release 99 one or more of the following shall provide the execution environments: 

• MExE 

• SIM Application Tool kit (SAT) 

• CAMEL 

12 Charging requirements 

Services, which are provided as part of the VHE, may be subject to charge at the discretion of the home environment 

There are several forms of charging which shall be available to the home environment. It shall be possible for the home 
environment to charge in the following instances: - 

- Subscription; 

the user's registration to use services may be subject to charge; 

- Service transfer; 

the transfer of services and/or information to the user MS or USIM may be subject to charge; 

- Service upgrading; 

the upgrading of previously transferred services to the user's MS or USIM may be subject to charge 
(automated upgrading of services may be subject to a different charge); 

- Service usage; 

the usage of services by a user may be subject to a charge; 

- Roaming 

the usage of VHE services when roaming may be subject to additional charges; 
Refer to UMTS 22.15 for further details. 
Other charging requirements may be identified and are for FES. 
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1 3 Security requirements 



The mechanisms supporting VHE shall maintain a secure environment for the user and home environment. 
The specific security requirements are FFS. 



Annex A (Informative) 



The following table shows the service examples to be considered in VHE 



Benchmark Services 


Abb 


Priority 


Abbreviated Dialling 


ABD 


A 


Account Card Calling 


ACC 


B 


Automatic Alternative Billing 


AAB 


A 


Call Distribution 


CD 


A 


Call Forwarding 


CF 


A 


Call Hold 


CH 


A 


Call Rerouting Distribution 


CRD 


A 


Call Transfer 


TRA 


A 


Call Waiting 


CW 


A 


Completion of Call to Busy Subscriber 


CCBS 


A 


Conference Calling 


CON 


A 


Credit Card Calling 


CCC 


B 


Destination Call Routing 


DCR 


A 


Follow-Me Diversion 


FMD 


A 


Freephone 


FPH 


A 


Global Virtual Network Service 


GVNS 


A 


Hot Line 


HOT 


A 


International Telecommunication Charge Card 


ITCC 


B 


Internetwork Freephone 


IFPH 


A 


Internetwork Mass Calling 


IMAS 


A 


Internetwork Premium Rate 


IPRM 


A 


Internetwork Televoting 


IVOT 


A 


Malicious Call Identification 


MCID 


A 


Mass Calling 


MAS 


A 
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Message store and forward 


MSF 


A 


Multimedia 


MMD 


B 


Originating Call Screening 


OCS 


A 


Premium Rate 


PRM 


A 


Security Screening 


SEC 


A 


Selective Call Forward on Busy / Dont' answer 


SCF 


A 


Split Charging 


SPL 


A 


Televoting 


VOT 


A 


Terminating Call Screening 


TCS 


A 


Terminating Key Code Protection 


TCKP 


B 


Universal Access Number 


UAN 


B 


Universal Personal Telecommunication 


UPT 


A 


User-Defined Routing 


UDR 


B (FFS) 


Virtual Private Network 


VPN 


A 



Benchmark services listed above could be realised by service capability features. 
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Annex B (informative): 
Change history 



Change history 


TSG_SA 


TDoc. No. 


CR. No. 


Section 
affected 


New 
version 


Subject/Comments 


SA#4, 
Miami 


SP-99237 


NEW 




3.0.0 


Specification Approved at SA#4 in Miami 


SA#5, 

Kyongju, 

Korea 


SP-99442 


002 
003 
004 




3.1.0 


Virtual Home Environment. 
Addition of IP4 Addressing 
Charging capabilities 
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